Codecov Report

✅ All modified and coverable lines are covered by tests.
⚠️ Please upload report for BASE (next-release@583acf4). Learn more about missing BASE report.

@@               Coverage Diff               @@
##             next-release    #1715   +/-   ##
===============================================
  Coverage                ?   98.75%           
===============================================
  Files                   ?       60           
  Lines                   ?     2655           
  Branches                ?        0           
===============================================
  Hits                    ?     2622           
  Misses                  ?       33           
  Partials                ?        0           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Hi @vemilano ,

We are planning to merge the branch v4-10-1, which contains changes in cargo_provider.py, into master branch.

You can resolve the potential conflict on this PR after we release 4.10.1.

cc @Lee-W

nit: you have typo in your commit message

I reviewed the commit in 4.10.1 and it should fix both issues. However, it changes one behavior: if there are both a workspace and a root package, it will bump the version of the workspace, and not the root package.

This might be unwanted behavior, as if there is a root package, this is probably the main project the author is working on.

We may want to get the version of the root package first (if it exists), and fallback on the version of the workspace.

What do you think of it @bearomorphism ?

Actually, I am not familiar with cargo files.

@Lee-W wdyt? Which behavior do you think is correct?

Hi @vemilano could you rebase? The current cargo_provider is quite different as of now. However, the behavior is the same. workspace is evaluated first. This has been done for simplicity and lack of "opinions" (we test workspace, and on failure we check project root). I usually either have a root version, or a shared workspace version, so it hasn't been an issue for me. Could you elaborate on why updating the root version first makes sense when they differ? thanks

For rebasing:

git remote add upstream https://github.com/commitizen-tools/commitizen.git
git fetch upstream
git rebase upstream/master
# fix conflicts
git add commitizen/providers/cargo_provider.py
git rebase --continue
git push origin fix/cargo-workspace-version -f

Hi @woile , apologies for the delay.

I checked 4.10.1and it fixes the issues I wanted to fix with this pull request, so rebasing should not be necessary. However, as you said, this version changes the priority of "version reading": firstly workspace version, then package version. It's ok in most cases, except (maybe) when we have both a package and a workspace in the Cargo.toml
With 4.10.1, in this case, it will bump the workspace version rather than the package version.

If a project have both package and workspace in the Cargo.toml, we might want to increase the version of the package, because it's often the main binary/library the author is working on. In this case, we should try to get package version first, then workspace version.

It's open to debate, I just wanted to mention this case so that we're sure of the final choice.

Sounds good to me, can you rebase and resolve conflicts?